1. Technical Field
The present invention relates to relational database management systems and, more particularly, to object relational interfaces for retrieving data from relational database management systems.
2. Description of the Related Art
Relational database management systems (RDBMS) are known for utilizing relational techniques to store and retrieve data in relational databases. Typically, a relational database is an electronic system for storing information in the form of tables (or relations). Each column in a table represents a field, or subdivision, for storing a specific data type. A table also includes a set of rows (or records) spanning its columns. Furthermore, data stored in columns of one table can form the basis of relationships between other tables in the RDBMS that have related columns. Using such a relationship, for example, two tables can be joined to provide a single table containing rows from one table combined with related rows from another table. Various high level languages, such as the Structured Query Language (SQL), can be used to store, retrieve, and delete data from the RDBMS. The high level language is used to define a query denoting a set of commands for retrieving data stored in the database.
Object-oriented programming methodologies can also be used to perform operations on the database. In an object-oriented environment, objects encapsulate related data and procedures in order to hide such information from the remainder of the program, thereby allowing access to the data and procedures only through the object's interface. Thus, changes to the data or procedures of the object are relatively isolated from the remainder of the program.
Many applications are designed to operate in an object-oriented environment and interact with an RDBMS in order to store and retrieve data. In order to interact with the RDBMS, an Object-Relational (OR) layer is provided to translate the relation between objects in the object-oriented environment and tables in the RDBMS. This is done using a relational mapping schema (or mapping metadata) to encode three types of information.
FIG. 13 is a diagram illustrating some of the different types of information that can be included in the relational mapping schema (or mapping metadata) according to one conventional methodology. For example, a system having an RDBMS with two tables is designated using reference numeral 610. The first type of information encoded provides a description of the tables and columns. This may include, but is not limited to a description of the tables and columns that exist, any foreign key constraints, unique constraints, nullability constraints, and even domain specific check constraints.
FIG. 13 also illustrates an object model that describes the attributes of objects 612 that are mapped to the tables 610. The second type of information encoded relates to the object model. This kind of information can include, but is not limited to, a description of the object types, attributes, and associations that comprise the domain model, as well as any properties that participate in the logical identity of an object type. Finally, the relational mapping schema would include mapping metadata 614 which describes how the object model maps to the tables. The mapping metadata 614 can include, but is not limited to, a description of which columns are used to store properties of the object model, and what joins are required in order to fetch associations.
At least one challenge encountered when designing OR layers is the efficient use of the relational querying capabilities provided in a supplier's backend datastore. A technique frequently used to address this problem requires an application program interface (API) that sidesteps the abstraction provided by the OR layer. This allows the developer to specify arbitrary SQL queries against the relational schema. The OR layer can then either provide the developer direct access to the data from these queries, or use the queries to efficiently read in, and resurrect, object data. However, the developer must have a thorough understanding of the RDBMS in order to provide programming code and/or SQL queries specific to the application and the relationship to the RDBMS. This approach, however, tends to violate the abstraction provided by a good OR layer. There is also increased development overhead associated with making changes to the relational schema. Further, if a change is made to the RDBMS relational mapping schema, the developer must recode the programming code and SQL queries. This can limit the scalability of an application because large amounts of data must be read from the RDBMS and, depending on the system architecture, transferred over the network.
Another approach to designing OR layers is to provide an Object Query Language (OQL) that allows the developer to describe queries in terms of the object model instead of directly using the backend datastore's native querying capabilities. The OR layer can then translate these logical queries into native queries tailored to the particular relational schema that has been chosen for the given object model. At least one drawback of this technique is that queries used to perform the filtering on the RDBMS are not captured as part of the object model of the application, even though they may directly describe a commonly traversed association, e.g., an association between a folder and a subset of its children. Further, common patterns in queries will not be part of the object model, and cannot be captured as associations capable of being reused. Consequently, large sections of such queries must be duplicated in order to perform related queries.